Migrating from Notes R3 to Notes R4: An Overview

Migrating from Notes R3 to Notes R4

Lotus Development Corporation anticipates that Notes R3 customers will be eager to migrate to Notes R4 in order to take advantage of the product's many enhancements. These include easier user access to the power of Notes, significantly improved mobile/disconnected computing, better application development tools, enterprise server support, superior client-server messaging, and seamless Internet integration. Notes R4 has a new mail user interface that is virtually identical to cc:Mail, enhanced replication capabilities, and improvements in performance, scalability and ease of use.

Because the benefits of Notes R4 are so compelling, customers will probably find it easy to understand why they should migrate. Having made that decision, customers will naturally be more concerned about how they can manage the migration. Lotus has concentrated its development and support efforts to make the Notes R3 to Notes R4 migration:

Smooth Migration

Product migrations usually involve a "coexistence" period which may at times involve disruptions. Lotus, however, has designed Notes R4 in a way that minimizes the coexistence period and makes migrating to Notes R4 a straightforward and non-disruptive process. Migration is made seamless primarily by the fact that Notes R4 is compatible with Notes R3. This compatibility means that:

Because the two environments are entirely compatible, coexistence should be painless, and migration should proceed without snags. The duration of any organization's coexistence period will depend on many factors, such as the number of servers and users that need to be migrated, the number and location of remote sites, and the size of the IT staff. Therefore, Lotus recommends that customers perform considerable planning and analysis before launching their migration efforts

Phased Migration

Lotus strongly recommends that customers migrate Notes in the following sequence: Notes servers, then Notes clients, then Notes applications. There are three advantages to this sequence.

First, organizations that follow this sequence will experience the smoothest migration. and ensure that disruptive situations are minimized. For example, applications will not be enhanced with Notes R4 features before users can access those features. It also avoids a situation in which users of R4 clients attempt to use new R4 features that are not available yet because a Notes R4 server is not available.

Second, there are specific features of Notes R4 servers that can be exploited by Notes R3 clients that will have a significant beneficial impact on the cost of ownership.

Third, migrating servers before the clients gives administrators a chance to become familiar with Notes R4 before rolling the new client software out to end users.

Server migration can be further broken down into the following recommended order: first hub servers, then user servers, then servers running other products. Hub servers should be migrated first because users don't generally access them, which means that if problems occur during the initial migration users aren't as likely to be affected. User servers, such as those that handle mail and applications, should be upgraded next. For servers running other products (gateways, etc.), organizations might want to wait until Notes R4 versions of those products become available before migrating the server.

Phase 1: Server migration. Upgrading a server is fairly simple. You install the server software and upgrade the Name & Address Book. Notes will automatically convert the file format and recreate indices for all databases the next time it runs COMPACT and UPDALL. Or you can run these steps manually.

These server processes can take several hours each depending on the amount of Notes data on the server and the speed of the server's processor. Lotus recommends measuring how long it takes to upgrade the first few servers and then using these metrics to estimate what a realistic daily upgrade load will be for the remaining servers in the organization.

Phase 2: Client migration. As with servers, this is fairly short and simple. Notes will automatically convert the desktop file format and create the Personal Address Book with entries from the Notes R3 Personal Address Book. Users can upgrade from any Notes R3.x release, but upgrading from R2 has not been tested as extensively as from Notes R3. The full version of the Notes R4 workstation software requires a minimum of 40 Mbytes of disk space.

Phase 3: Application migration. Bringing Notes R3 applications forward into Notes R4 is simple, since existing Notes R3 applications will work on Notes R4 without modification. As an extra precaution Lotus recommends testing mission-critical applications, as well as applications that contain "representative" functionality that is, functionality used in other applications.

Once the servers and workstations are running Notes R4, administrators can safely begin to introduce new Notes R4 functionality into existing applications and can create new applications using features introduced in Notes R4. The "golden rule" regarding applications is this: Do not add new Notes R4 functionality to applications that Notes R3 users will access. That's because Notes R3 users will receive error messages if they try to use parts of the application that are Notes R4-based. The error messages may give users the incorrect impression that there is something wrong with the system, and users may develop a negative impression about Notes R4. This may also lead to an increase in end-user calls to your internal support staff.

All server- and client-based API programs, including OLE- and FX-enabled applications, will run unmodified after upgrading to Notes R4, with one exception. The exception occurs when customers move from 16-bit Windows (Windows 3.x) to 32-bit Windows (Windows 95 or Windows NT) while at the same time moving from the 16-bit Windows version of Notes to the 32-bit Windows version of Notes. In this case other programs that interact with Notes, such as spreadsheet and word processing programs, will have to be upgraded to 32-bit versions. In other words, as long as Notes and the other programs that interact with Notes are all 32-bit, the applications that have been developed using Notes and the other programs will run unmodified.

Straightforward Migration

For some organizations, the migration to Notes R4 will not be their first experience in a major Notes migration. In fact, for those organizations that upgraded from Notes R 2.x to Notes 3.0 will recall that the migration was not as straightforward as possible. A number of factors contributed to this, and Lotus has fully incorporated the lessons it learned from that migration into its plans for migrating customers to Notes R4.

Interoperability. Initially, Release 3.0 of Notes had some problems interoperating with Release 2.x. These problems were resolved but not before some customers experienced difficulties. As they roll out Notes R4, customers will benefit from the comprehensive interoperability testing that Lotus has conducted, and customers migrating to Notes R4 should expect smoother interoperability this time than they might have experienced when migrating to Notes R3.

One factor that contributed to the interoperability problems in the R2-Notes R3 migration was the fact that in Notes R3 Lotus added support for several new operating systems and networking protocols all at once. In hindsight it is clear that such an ambitious endeavor could lead to some problems. Nevertheless the minor glitches in the various implementations were resolved early in the Notes R3 product life. Now, as Lotus moves from Notes R3 to Notes R4 it does so on a very stable foundation.

Systems software expertise. Lotus has become more capable as a vendor of systems software. Selling systems software requires a different mindset and business model than selling desktop software. At the time of the Notes R3 introduction and migration Lotus was still establishing itself as a leading systems software vendor. Since then, Lotus has focused energy internally on improving its support and services as a systems software developer. Now as a subsidiary of IBM, Lotus is benefiting from an infusion of world class systems software personnel and experience.

Complete migration resources. Perhaps the biggest problem in the Notes R3 rollout was that Lotus did not provide adequate product migration information to customers. With Notes R4 Lotus is making available a variety of resources, including the following:

Five Stages of a Notes Migration Project

A major product migration does not take place in one fell swoop, but in stages. There are five stages to a full migration: planning, preparation, pilot, production and leveraging. For some customers there will also be a rollback stage, although this is likely to be a rare exception rather than the rule.

Planning. Pre-migration planning is probably the most critical element of a successful migration. Time invested here will save time later in the project and result in a quicker overall implementation with fewer snags and headaches. During the planning stage new features in Notes R4 should be evaluated and "big wins" should be identified. Also a detailed upgrade schedule should be created. As part of the planning stage, customers should pay careful attention to infrastructure changes that are also being planned and to Notes-specific database and template changes that may be necessary for a successful migration.

It is a good idea to consider changes related to hardware, operating systems, networking protocols, and LAN/WAN architecture. Some of the issues to address include:

Lotus cautions customers that they should not carry out infrastructure changes at the same time as the Notes upgrade. Customers should make infrastructure changes either before the Notes migration, when they are still using the familiar Notes R3 environment, or after the Notes R4 migration has been completed and the organization feels comfortable enough with Notes R4 to introduce other infrastructure-related variables. Naturally, customers should plan and test these changes thoroughly before mixing them with any Notes environment.

In addition, there are specific changes to Notes databases that require the attention of migration planners.

Preparation. In this phase the Notes R4 migration team should set up test and production environments. Also during the preparation phase customers should consider standardizing their Notes R3 environment on the latest maintenance release of Notes 3.x before beginning migration to Notes R4. This step is recommended only if very early versions of Notes R3 are in use, however it is not required.

Pilot. In this phase the migration team should conduct a pilot migration project and test the migration process. They should test the mission critical applications that have been brought forward onto the new platform. User training should begin in this stage.

Production. Once the pilot roll-out has been tested and proven to be production-ready, the organization can roll out the new version to servers and users across the enterprise. Careful planning and preparation should ensure that this transitional period proceeds quickly and without glitches.

Leveraging. Once Notes R4 has been deployed across the organization the IT organization can begin to take full advantage of the all of Notes R4's new features and capabilities. Customers should plan carefully to deploy Notes R4 applications that make use of these new features (e.g., collapsible sections, Navigators, etc.) only to users who already have migrated to a Notes R4 client. That is, Notes R4 enterprise-wide applications should wait until rollout is complete before implementing new features in order to avoid a situation where Notes R3 users find themselves unable to access new Notes R4 application features. Of course, most organizations will be able to identify some applications that are narrow enough in scope (e.g., team-level, group-level, department-level) that can exploit new Notes R4 features, as long as all prospective users of the application have migrated to a Notes R4 client. Also, as pointed out above, some Notes R4 server features can be exploited immediately, even by Notes R3.x clients.

Rollback. Customers should not have to roll back to Notes R3, since any combination of Notes R3/Notes R4 workstations and servers will interoperate. Nevertheless, Lotus recommends that customers know how to roll back databases and servers, if only for the comfort of having a contingency plan. Rolling back a database involves changing the database from the Notes R4 file format back into the Notes R3 file format. Notes includes a facility that makes this simple.

Conclusion

Lotus has done extensive compatibility and coexistence testing on Notes R4, and Notes R3 customers should be able to migrate to the new environment without experiencing disruptions in Notes services.

Lotus advises customers to remember that time spent in planning will make the implementation of Notes R4 go smoothly. Also Lotus cannot emphasize too strongly its recommendation that IT organizations follow the server-client-application migration sequence. Customers who follow these guidelines should experience an easy transition and will realize the benefits inherent in the Notes R4 environment almost immediately.

For more information, call Lotus at 800-343-5414 or visit the Lotus Home Page at www.lotus.com

Updated: 01/18/96 12:01:23 PM

This page created and managed with Lotus Notes and a pre-release (Beta 2) copy of Lotus InterNotes Web Publisher® Release 4.0.
License expires March 1, 1996.